The traditional database storage layout of disk-based databases involves fixed-sized data pages composed of table rows. The data pages are fetched from disk and maintained in a shared page buffer pool, for efficient usage by concurrent applications. The page size and structure is optimized for efficient disk input/output (I/O). The solution is not suitable for in-memory databases because the overhead of the shared page buffer pool is too large. Especially, several steps of indirect addressing are applied to access a single data item (e.g. a column value). Additionally, in in-memory databases, there is no need to buffer the data on the way from, or to disk. The solution is also called a row store, or a row-oriented database because of the row orientation of the page structure. Row store is beneficial in on-line transaction processing (OLTP) databases. This is because the number of columns is small, and several column values are likely to be processed in a database operation like insert or select. On the other hand, in a column store, or a columnar database, the data is organized by placing the column values close to each other. Columnar databases are suited for analytical processing, because the number of columns can be very large (even in the range of hundreds or thousands) and most query operations are column-wise. By placing the column values adjacently, the efficiency of disk I/O and memory access is improved. Especially, in modern hardware platforms characterized by asymmetric memory (exemplified by the Non-Uniform Memory Access (NUMA) architecture), multi-level memory caches and vector processing (single instruction multiple data (SIMD)) units, the advantage of processing the memory contents sequentially is significant. Thus, all current implementations of in-memory analytics databases employ large column objects allocated in memory. The disadvantage of that solution is that it does not allow for data migration between the memory and disk. The data migration is required because there is a need to free memory from the data that has not been used recently, and restore it when it is needed. In columnar databases, there is also a need to move cold (not used recently) columns from memory to disk.
Most in-memory databases are not designed for data migration. Typically, an in-memory table has to reside in memory in its totality. That also applies to columnar databases where column data is stored in fixed-size column vectors. One prior art solution, called anti-caching, applies moving of the data to disk on a row-by-row basis. That is not suitable to columnar databases when a need to migrate data on a column basis emerges.
Regarding the data organization in memory, various solutions are proposed, tending to balance the needs of the row-oriented and column oriented processing. However, no solution has been offered to the problem of efficient copying of values, in particular data migration.